Fix stack trace population to get proper source/line info for tier 1 methods #16302
Conversation
There was a problem hiding this comment.
Looks great. My only suggestion if you haven't already done it is to confirm we haven't regressed stack trace performance by manually running a micro-benchmark such as microsoft/dotnet#529.
I'm not anticipating you will find any issue but just want to do the due diligence.
|
In that test case I'm seeing a regression at steady-state (operations per ms): No tiering: Tiering: If this is significant I can look into how to reduce the regression. |
|
The error on those numbers is pretty high but the difference is significant |
|
I said significant twice with different meaning, I meant to say that there is definitely a repeatably measurable gap but I'm not sure if the gap is large enough to look into further.? |
|
@dotnet-bot test Tizen armel Cross Checked Innerloop Build and Test |
|
From a few profiles the gap might be due to getting the method start address. We can either do that lazily like now, or get it at the same time the MethodDesc is looked up and store it, I'm not sure if the latter would negatively affect other perf scenarios. |
|
I don't think 1-3% on this microbenchmark is worth fretting over. My imagination would be worst case someone complains about it and we look into it, but even there it would be in the context that something is running just slightly slower and it would be nice to speed it up. In 529 the regression was significant enough (2500%) that it blocked customers from reasonably performing the same tasks. |
Fixes https://github.com/dotnet/coreclr/issues/16224